哈嘍～各位觀眾～我們又在空中見面，歡迎各位來到FM 10.24，軟體廣播電台-「深夜聊工程」的節目，我是主持人 小笠宏樹

深夜時間我們來一首
Bob Marley - No Woman, No Cry

首先來跟大家介紹一下什麼是彼得原理
「彼得原理」是著名的管理學大師「勞倫斯·彼得」在1969年所出版的一本同名的書，裡面所提及的內容直到今日看在這世界上還是有眾多的例子再發生，裡面最具知名的便是這個推論，「當在一個階層式的組織架構中，員工會因為手上的工作表現好，而被逐漸的往更加上面的位子推（升遷），最後會升到一個他完全無法勝任的位子後就停了下來，最後導致的結果就是，『在位子上的人都是不擅長這個職位的人』」。
後續我之前推薦過的卡通呆伯特的作者也有對這個經典的原理作諷刺的延伸，解釋成「呆伯特原理」，大概的意思就是，「公司為了讓公司損害最低，於是會讓最不會做事的人不要待在第一線，而傾向將他們升到高位」，雖然說有點不現實感，但也有很多人也深表認同？

讓我們先進廣告，看一段我在找素材時找到的影片，你會發現這個世界到哪裡都會有一樣的管理問題XD
新東方學校《釋放自我》

好了～好笑的看完了～讓我們來解構一下彼得原理是怎麼發生的！
「小明是一個大公司的碼農，他不僅認真負責，總是能準時交付，並且程式碼的品質總是非常良好，後續也鮮少出現問題。於是某日他的老闆找他來，並請他擔任軟體架構師，這時小明非常開心他剛好早就想專研軟體架構方面的技術了。又過了一年，老闆非常興奮的升他為技術主管，這時小明的壓力也漸漸地大了起來，不過還好的是管理的人都是工程師，處理的也都是技術的導入，雖然手忙腳亂但也還有辦法撐著，但一年後，那個可怕的老闆又來找他了，這時候是想請他擔任他們所有技術的負責人，這時小明傻眼了，資料分析、財報需求、行銷合作、人事處理、供應鏈管理系統等等的問題如同隕石般向他砸來，於是他只能朝天吶喊『我可不可以安安靜靜的寫程式就好？！！』」

這在普通公司還蠻常見的，因為我們如何判斷一個員工可否升遷的關鍵就在於這個員工目前手上的工作是否有做好，但完全沒有考慮到升遷後的職能跟這位員工相不相符，因此導致最後員工會升遷到一個他所不能處理的職位上。

讓我們改一下這個敘述，通常我們在決定要把一群Class中抽出個抽象層當Parent Class的時候，你會找function最多、細節最多的Class當Parent Class的範例嗎？這樣子會改到死吧（笑，所以通常我們必須要找的是可以最彈性，甚至是邏輯上最簡單的Child Class當Parent Class的範例。

以下我們來用這個的角度給各位幾個公司上的建議吧～

1. 如果正在被提拔升遷，必須知道升遷不代表一定是好事，而是需要轉換職能，因此讀者要先去想想可不可以以及想不想要承擔很不一樣的工作內容及環境。甚至很多過來人的經驗也都會說太早身居高位不是什麼好事（當抽象化後要再掉回Child會極其痛苦）。
2. 對於管理者來說，請記得多信任你的Child Class，把細節盡量交給他們處理，謹記主管的重要職責是將上面所傳下來較模糊的指令轉換成較為精確Child Class可以理解的任務或是阻擋上面傳下來不恰當的指令，另外要記得關注下屬們是否有新的好的作業邏輯可以再一起被抽象化成共用的SOP，並作成abstract function半強迫下屬去遵守好的規則，也要時常把不好的沒在用的SOP刪除。
3. 當公司要選一位員工當管理者時，記得給予員工跟公司都多一點時間處理職能抽象化的過程，有些公司會建立管理職得先修課程，有些會先給予試用期間，甚至有人會直接在初期時就安排儲備幹部的訓練，這些都是為了處理彼得原理所提出來的質疑。

好了，在今天我們簡單的利用前述的概念重新定義了工程版的彼得原理，「當你將一個細節做最好最多的Child Class作抽象時，那抽象化的過程會異常的辛苦，並且會有許多不適合的地方。」希望大家能理解這個原理。
最後給大家一個思考題，這個我自己也還沒有一個完全正確的答案，通常大家批評「彼得原理」的時候，也會將KPI制度納入進去批判，這時候就會分成兩派「KPI的對與錯」，那假如依照此篇文章剛剛討論的方向，到底我們如何評判一個Child Class比較適合當作Parent Class的模板？而這又要怎麼帶入到現實的管理上呢？

明天要聊的是SOP的好與壞，也歡迎大家來猜猜看內容會是什麼～